# Zombie Navigator Design

## TODO

- Develop a postprocessor for `jpm`-built packages (PKZIP-based)
  - In what language?
  - Optimization and reproducibility "fixes"
  - With Google's Zopfli `deflate` compressor
  - Bundle Zopfli and postprocessor for bit-to-bit reproducible builds
- Try not to bloat the codebase
- Unified policy manager for scripts
- Create a "Running Scripts" page?
- Make sure the API is always reliable
  - Develop a complete testsuite
- Per-script user controls??
- 0.6: Remove JSDoc
  - We need a minimalistic approach to this (generated docs)
  - Write a script to generate the documentation to embed in the package
- 0.6: Implement a generic downloader (No interaction permitted: *just* downloading to the default directory, unlike XHR) (only possible with non-SDK `Downloads.jsm` ?)
  - The functionalities of `Downloads.jsm` should be made available in SDK, really. Not because they want no more "downloaders" in AMO?
- *Reset* preferences on uninstall (so that the next installation will be "fresh")?
- Use NodeJS for build scripts? (but remember we *hate* `npm` and `semver.org`)
- Find any problems related to e10s (should be fixed by SDK team)
- Research: more sophisticated management of scripted browser session/tabs
  - Bind each script to the respective status window
  - Open a window before runnning script based on the policy
  - Close the window -> terminate the script
- *Zombie Navigator Studio* -- A graphical frontend and script collection manager for Zombie Navigator
  - Develop GUI-oriented features in this project instead


## Coding policy

- Addon: No dependencies outside Firefox
- Try to be as pure-SDK as feasible
- No new features in Beta or Stable (branched out)
- Make it unlikely to break in future Firefox
- Tiny code base and minimum-sized build
- Feel free to use ES6 as implemented in Firefox 38+ (let/const are OK but be careful)
- Use only High-Level SDKs for web contents
- Use wrappers for SDK access (`Addon SDK Abstraction Wrapper` in `platform/`)
  - Avoid duplicate codes and increase maintenability to produce more secure codes
  - Make it easier to port the addon to possible future platforms
  - Restrict what the addon code can do with the SDK
  - Isolate codes to make it substantially harder to exploit the addon
  - Clarify the privileges of each module
- Plain SDK access should be forbidden throughout the addon (except wrappers)

### Development policy

- Localization is of a low priority
- This addon is of the kind where backword/forward compatibility matters
- Stable API

### Firefox compatiblity

- Support **the latest ESR release and later (normal) release versions**
- No breaks in **Beta**
- Fix problems in **Nightly and Aurora**
- Support **the previous ESR release until becoming obsolete**
- Support **GNU/Linux i386 and x86_64**
- Support **Debian Iceweasel (stable)**
- Support **GNU Icecat**
- Try to fix issues with other distribution packages
- Accommodate *customized Firefox-based products*
- No support planned for Fennec
- No *official* support for Microsoft Windows (may work)
- No *official* support for Apple OS/X (may work)
- Will NOT support the coming "Firefox for iOS," which is not much of Firefox
- Try to support FreeBSD's Linux emulation
- May support GNU/Hurd once it becomes possible in the future
- Now e10s seems to work (depends on SDK's reliable e10s support)

### Addon behavior

- No action unless told to do something
- No visible UI outside `about:addons` if not requested
- No network access by default (required resources are all packed into the addon package)

### Security

- Zombie scripts cannot control the whole browser
- Zombie scripts have no direct access to local file system
- Zombie scripts can only control or otherwise access the tabs they opened
- Zombie scripts cannot save persistent data to the browser (beside history, which is handled by user or Private Browsing)
- Thus no chrome access is allowed for Zombie scripts
- Also no unrestricted or raw access to Addon SDK
- Security may partially break if the user messes up the automated browser manually

### Coding styles

- Care about consistency of coding styles
- UTF-8 as the preferred text encoding whenever possible (ASCII is a UTF-8 subset)
- Indentations use a single tab (U+0009) and each represents 4 spaces (Space matters)

### Branding

We named this program "Zombie Navigator" because it effectively turns
Firefox into an automated "zombie" web browser. "Zombie scripts", which
run inside a secure sandbox navigate Firefox!

The icon says "Web Browser" in Arabic. Just that. Maybe too simple. But we
do not invest much in visual design.

Firefox is a registered trademark of the Mozilla Foundation. The term
"Firefox" in this product, however, may also mean rebranded products
derived from the official Firefox.


### Versioning

- https://github.com/mojombo/semver/issues/145
- We use `~` for prereleases (compatible with AMO)


